QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/tcp/940202.txt

Internet Message Format | 1994-11-13 | 66KB

Date: Wed, 14 Sep 94 04:30:02 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #202
To: tcp-group-digest


TCP-Group Digest            Wed, 14 Sep 94       Volume 94 : Issue  202

Today's Topics:
                 ax25 linux implementation? (8 msgs)
                     Cross compile NOS with gcc?
                             Mail failure
               TCP-Group Digest V94 #197 (fwd) (2 msgs)
                             TEKK prices

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Tue, 13 Sep 1994 07:34:25 -0700
From: [e-mail] (Brian Kantor)
Subject: ax25 linux implementation?
To: [e-mail]

I believe that I'd do AX.25 a different way than is being discussed.

I'd like to have an AX.25 routing table.  Each port would have an
AX.25 'quality' or 'precedence' value assigned to it.  Whenever a
station is heard, an entry is made in the axrt table for that station,
weighted with the 'precedence' of the interface from which the station
was heard, and timestamped so that it can be expired.  It would be
possible to include digipeater chains in the table for the places where
they are necessary.

A utility would exist to enter stations into the table manually, and to
flag appropriate entries as unexpireable.  One interface could also be
designated the default for stations whose callsign/ssid don't appear in
the table at all.

Packets to be sent from any socket or protocol to the AX.25 layer would
be routed according to this table.  Higher-level protocols such as ARP
therefore don't need to know interface names.

The ARP table, therefore, need only resolve the IP address to a
hardware address and type, where the type is either Ether or AX25, and
the address is the 48-bit Etheraddr or the 6.5 byte AX25 callsign.

The AX25 and Ether ARP tables can be separate or combined.  Personally,
I'd do them separate.

This also means that there should be an AX25 pseudo-device.  The
routing at the IP level would resolve to a device (Ethernet, PPP, SLIP,
ENCAP, or AX25), and those that need it (Ethernet, AX25) would do ARP.
The AX.25 pseudo-device could also handle digipeating if you want to.

If you're going to do Net/Rom, that should be a pseudo-device with its
own routing table.  Again, if an IP address resolves to a net/rom
pseudo-device, then the net/rom pseudo-device would route it to the
AX.25 pseudo-device, which would in turn ship it off to the right port
according to its routing table.  (There should be an ARP at this point,
but net/rom can't do ARP as far as I know, so it's all manual entries
and n/r routing [much like RIP] in that table.)

I don't believe Linux does it this way.  It was what I was going to do
with the BSD kernel mods, but personal matters came up and so I've
turned that project over to you guys.

Have fun!
        - Brian

------------------------------

Date: Tue, 13 Sep 1994 18:27:25 -0700 (PDT)
From: Lyndon Nerenberg <[e-mail]>
Subject: ax25 linux implementation?
To: Brian Kantor <[e-mail]>

> I'd like to have an AX.25 routing table.  Each port would have an
> AX.25 'quality' or 'precedence' value assigned to it.  Whenever a
> station is heard, an entry is made in the axrt table for that station,
> weighted with the 'precedence' of the interface from which the station
> was heard, and timestamped so that it can be expired.  It would be
> possible to include digipeater chains in the table for the places where
> they are necessary.

You have a potential problem with hearing a station direct and also via a
digi on the same interface. This used to happen to me with NOS and would
lead to asymetrical "route flapping" at the MAX (AX25) layer. In essence,
I would establish a direct connect to the remote, the remote would
establish the reciprical path, then I (NOS) would hear the remote via a
digi, update the ARP table to use the digi path instead of direct, and
the connect would go into hyperspace as the remote continued to use the
direct path and NOS would respond via the digi.

Mind you, this was an AX25 VC connect (between NOS and F6FBB software).
If you're running IP inside of AX25 datagrams I would think that you
could have the receiver ignore any MAC layer routing information on the
incoming packets, as long as the destination MAC address matches
something your interface is responding to.

How do you handle the situation where you have a direct and one or more
digi paths to the remote? The shortest path isn't necessarily the best,
and this may vary with the time of day (it does here quite often).
Perhaps we need to maintain a (time decayed) count of the number of
sucessfully received packets for each path in the ARP tables? This
isn't very reliable, though, as it is easily skewed by the traffic
patterns of the sending station.

--lyndon

------------------------------

Date: Tue, 13 Sep 1994 18:57:58 -0700
From: [e-mail] (Brian Kantor)
Subject: ax25 linux implementation?
To: [e-mail]

The way you handle direct vs digi paths to stations is

1) get rid of the digi.  Dynamite is good  Digipeaters suck hard and
really need to be gotten rid of as fast as possible.  If this helps, so
much the better.

2) lock the route down manually
    - Brian

------------------------------

Date: Wed, 14 Sep 1994 12:16:20 +0930 (CST)
From: Rob <[e-mail]>
Subject: ax25 linux implementation?
To: [e-mail]

As a side issue, has anyone succeeded in getting Linux to work on an HP
Omnibook 530S ? Would make a nice mobile ip setup :-)

Rob

--
rob mayfield snr tech/analyst *nix/network admin asc p/l box 73 oaklands park
[e-mail] vk5xxx@vk5xxx.#adl.#sa.aus.oc     s.aust 5046

------------------------------

Date: Wed, 14 Sep 1994 12:54:36 +0930 (CST)
From: Rob <[e-mail]>
Subject: ax25 linux implementation?
To: [e-mail] (Brian Kantor)

*** In reply to mail from Brian Kantor, ....:
> The way you handle direct vs digi paths to stations is
>
> 1) get rid of the digi.  Dynamite is good  Digipeaters suck hard and
> really need to be gotten rid of as fast as possible.  If this helps, so
> much the better.

This'll give the digi 'a larger coverage area', is this what we want ?

Dozing it in might be safer ... ;-)

--
rob mayfield snr tech/analyst *nix/network admin asc p/l box 73 oaklands park
[e-mail] vk5xxx@vk5xxx.#adl.#sa.aus.oc        s.aust 5046

------------------------------

Date: Wed, 14 Sep 1994 09:33:31 +0200 (BST)
From: [e-mail] (Alan Cox)
Subject: ax25 linux implementation?
To: [e-mail] (Brian Kantor)

> The way you handle direct vs digi paths to stations is
> 1) get rid of the digi.  Dynamite is good  Digipeaters suck hard and
> really need to be gotten rid of as fast as possible.  If this helps, so
> much the better.
> 2) lock the route down manually

There is a lot to be said with living in the current world where (alas)
digipeaters and flexnet and stuff need to peacefully coexist. This business
of auto-routing v not auto-routing was an interesting one. I chose to make
Linux bind to a port and connect via that port (ie client picks the port)
because firstly I had a real situation where I needed to force ports all
the time and secondly by not binding to an address the current code goes
Nope! but new code can auto route. Indeed John Naylor (G4KLX) has added
a route learning piece to the code but not yet the route picking part. Having
a route cache is also useful for one other thing - you get a free MHEARD
(or ax25 heard to ka9q'ers) list.

However its done being able to run mosaic over amateur radio is nice 8)

Alan

------------------------------

Date: Wed, 14 Sep 1994 06:17:50 -0400
From: "Brandon S. Allbery" <[e-mail]>
Subject: ax25 linux implementation?
To: [e-mail]

In your message of Wed, 14 Sep 1994 12:54:36 +0930, you write:
+---------------
| 1) get rid of the digi.  Dynamite is good  Digipeaters suck hard and
+------------->8

It occurs to me that digis are about as likely to disappear as *.NA is.

++Brandon
--
Brandon S. Allbery KF8NH     [44.70.4.88]        [e-mail]
Linux development:  iBCS2, JNOS, MH                     ~\U
Daily dreading Nehemiah Scudder^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HRush Limbaugh

------------------------------

Date: Wed, 14 Sep 1994 05:36:11 -0500 (CDT)
From: Gerald J Creager <[e-mail]>
Subject: ax25 linux implementation?
To: [e-mail] (Rob)

Rob sez:
>
> *** In reply to mail from Brian Kantor, ....:
> > The way you handle direct vs digi paths to stations is
> >
> > 1) get rid of the digi.  Dynamite is good  Digipeaters suck hard and
> > really need to be gotten rid of as fast as possible.  If this helps, so
> > much the better.
>
> This'll give the digi 'a larger coverage area', is this what we want ?
>
> Dozing it in might be safer ... ;-)

With dynamite, you disperse it overa larger area both reducing the overall
impact of the original problem, and making it harder for the EPA to figure out
what it was to cite you.  If you doze and bury it, it's a point source of
contamination... ;-)

Gerry

------------------------------

Date: Tue, 13 Sep 1994 09:40:38 -0800 (PDT)
From: [e-mail] (John Paul Morrison)
Subject: Cross compile NOS with gcc?
To: [e-mail]

Does NOS build with gcc? Does it run properly? I'm wondering if the
DJGPP or EMX (in DOS, not OS/2) compilers are usable. If they are, I
don't even have to compile under DOS, because there are utils for GCC
to let you cross compile under UNIX, and produce DOS .exe's.

---------------------------------------------------------------------------
BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM
-- [e-mail] [e-mail]
[e-mail]
---------------------------------------------------------------------------

------------------------------

Date: Tue, 13 Sep 94 19:57:00 edt
From: Adminstrator <[e-mail]>
Subject: Mail failure
To: dayhub!3445a!ucsd.edu![e-mail]


User mail received addressed to the following unknown addresses:
  GPPGDAYTON/GPPGPOST/lshannon

------------------------------------------------------------------------------
Return-Path: <dayhub!3445a!ucsd.edu![e-mail]>
Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id
    <[e-mail]>; Tue, 13 Sep 94 19:57:15 edt
Received: by prowler.daytonoh.ncr.com; 13 Sep 94 13:18:21 EDT
Received: by dayhub.DaytonOH.NCR.COM; 13 Sep 94 13:18:13 EDT
Received: by 3445a.DaytonOH.NCR.COM; 13 Sep 94 13:17:43 EDT id AA779477717
    Tue, 13 Sep 94 13:35:17 EST
Date: Tue, 13 Sep 94 13:35:17 EST
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TCP-Group Digest V94 #201


Received: by ccmail from 3445a.DaytonOH.NCR.COM
>From ncrhub1!ucsd.edu![e-mail]
X-Envelope-From: ncrhub1!ucsd.edu![e-mail]
Received: by 3445a.DaytonOH.NCR.COM; 13 Sep 94 13:14:36 EDT
Received: by dayhub.DaytonOH.NCR.COM; 13 Sep 94 13:14:19 EDT
Received: from ncrgw1 by ncrhub1.NCR.COM id ar05029; 13 Sep 94 13:13 EDT
Received: by ncrgw1.NCR.COM; 13 Sep 94 12:52:01 EDT
    sendmail 8.6.9/UCSD-2.2-sun
    Tue, 13 Sep 1994 04:30:10 -0700 for tcp-digest-list
Received: by ucsd.edu; id EAA01122
    sendmail 8.6.9/UCSD-2.2-sun
    Tue, 13 Sep 1994 04:30:08 -0700 for tcp-group-ddist
Message-Id: <[e-mail]>
Date: Tue, 13 Sep 94 04:30:03 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #201
To: [e-mail]

TCP-Group Digest            Tue, 13 Sep 94       Volume 94 : Issue  201

Today's Topics:
                             Mail failure
                             SCC = Baycom

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 12 Sep 94 11:48:00 edt
From: Adminstrator <[e-mail]>
Subject: Mail failure
To: dayhub!3445a!ucsd.edu![e-mail]



User mail received addressed to the following unknown addresses:
  GPPGDAYTON/GPPGPOST/lshannon


------------------------------------------------------------------------------

Return-Path: <dayhub!3445a!ucsd.edu![e-mail]>
Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id
    <[e-mail]>; Mon, 12 Sep 94 11:48:51 edt
Received: by prowler.daytonoh.ncr.com; 12 Sep 94 11:42:14 EDT
Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 11:42:06 EDT
Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 11:42:13 EDT id AA779385538
    Mon, 12 Sep 94 11:58:58 EST
Date: Mon, 12 Sep 94 11:58:58 EST
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TCP-Group Digest V94 #200


Received: by ccmail from 3445a.DaytonOH.NCR.COM
>From ncrhub1!ucsd.edu![e-mail]
X-Envelope-From: ncrhub1!ucsd.edu![e-mail]
Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 11:37:40 EDT
Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 11:37:14 EDT
Received: from ncrgw1 by ncrhub1.NCR.COM id aa27896; 12 Sep 94 11:33 EDT
Received: by ncrgw1.NCR.COM; 12 Sep 94 11:32:25 EDT
    sendmail 8.6.9/UCSD-2.2-sun
    Mon, 12 Sep 1994 04:30:08 -0700 for tcp-digest-list
Received: by ucsd.edu; id EAA24362
    sendmail 8.6.9/UCSD-2.2-sun
    Mon, 12 Sep 1994 04:30:06 -0700 for tcp-group-ddist
Message-Id: <[e-mail]>
Date: Mon, 12 Sep 94 04:30:01 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #200
To: [e-mail]

TCP-Group Digest            Mon, 12 Sep 94       Volume 94 : Issue  200

Today's Topics:
                               autoampr
                      ax25 linux implementation?
                             Mail failure

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Sun, 11 Sep 1994 12:20:39 -0600
From: [e-mail] (Bdale Garbee)
Subject: autoampr
To: [e-mail], [e-mail]

I made a comment on one of the mailing lists the other day about having put
together some bits and pieces to help automate the management of an ampr.org
subnet.  A couple of folks contacted me asking for copies of the code.  I
wrote up a README file, shar'ed and gzip'ed it all, and you can acquire it
from

 ftp://winfree.gag.com/packet/gateways/autoampr.shar.gz

Don't bother unless you've got a Unix machine nearby, it's all shell script.

I hope it's useful to someone, has made my life a wee bit simpler.

73 - Bdale, N3EUA

------------------------------

Date: Mon, 12 Sep 1994 10:06:25 +0200 (BST)
From: [e-mail] (Alan Cox)
Subject: ax25 linux implementation?
To: [e-mail] (Glenn Davis)

> Thanks for the feedback on what an AX.25 bsd socket should do.  Can you
> tell me where to find the Linux implementation (source) ?  I will model
> my port after Linux.  Also, there was mention of a few applications built
> on this model; where might they reside?

All reside on ftp.linux.org.uk:/pub/Linux/Radio. The code is derived from
netccitt so you shouldn't have any trouble comparing it against your
netccitt code. The tools that exist currently in the main set are

 call - AX.25 connect program with YAPP support
 axl - An AX.25 listener - spawns a program for each AX.25
   connect [think of it as a dumb inetd]
 pms - Very crude PMS I wrote basically to prove I could
   rewrite AX.25 bulletins/mail into RFC822 and provide
   useful received from lines. Others are now working
   on this.
 axarp/axdelarp/axaddarp - original AX.25 arp manipulation. The current
   Linux net tools support AX.25 implicitly now so no
   special tools are used.
 listen - This won't port as it uses SOCK_PACKET (raw interface
   sockets) to monitor AX.25 KA9Q trace style. It's
   derived from the KA9Q trace routines.

 beacon - Send a regular beacon (dameon process)

 axattach - Attach an AX.25 iface (mirror of slattach)
 axsetcall - Set the AX.25 MAC address on an AX.25 interface
 mheard - List who has been recently heard. This uses the
   ax.25 routing table still under addition but collecting
   lists.

On ftp.ucsd.edu you will find the source to some raw socket stuff for talking
to microsat's. You'll also need the xview3 open windows toolkit to build this.
Other people are working on doing BBS code, I'm currently playing with a
very nice hostmode terminal for unix that I want to change to use AX.25
kernel sockets.

If you have any great ideas or think I've done something a paticularly stupid
way then I'm very open to suggestions. I'd rather we had one standard that
works
than one that works sort of, even if it means changing the Linux version of
the code.

> I just spent 8 hours finishing the ARP code.  It appears that ARP's are
> not used on point-to-point links normally.  If I read the code correctly
> BSDI just drops them on the floor.  This causes problems since you want
> the interface that the packet arrived on, and this is not available when
> you dequeue the mbuf.
>
> How did the Linux implementation solve this?  My solution was:

Linux doesn't consider the interface point-to-point in AX.25 mode (only
in SLIP mode). The data always happens to be available so that one never
occured. axattach on a (previously) SLIP link clears the pointopoint flags.

The one that was harder to fit nicely into the BSD socket semantics is the
opening phase. I added a little piece of code so that the commonly seen

 SABM
 [wait]
 SABM
 UA
 [Connected]
 UA
 [Reset Connection, Connected]

Doesn't cause a connection refused on the socket but waits until it opens
properly. If data has been sent and another UA turns up then it does reset.

Alan

------------------------------

Date: Mon, 12 Sep 94 06:43:00 edt
From: Adminstrator <[e-mail]>
Subject: Mail failure
To: dayhub!3445a!ucsd.edu![e-mail]



User mail received addressed to the following unknown addresses:
  GPPGDAYTON/GPPGPOST/lshannon


------------------------------------------------------------------------------


Return-Path: <dayhub!3445a!ucsd.edu![e-mail]>
Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id
    <[e-mail]>; Mon, 12 Sep 94 06:43:46 edt
Received: by prowler.daytonoh.ncr.com; 12 Sep 94 06:37:02 EDT
Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 06:36:52 EDT
Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 06:36:55 EDT id AA779367213
    Mon, 12 Sep 94 06:53:33 EST
Date: Mon, 12 Sep 94 06:53:33 EST
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TCP-Group Digest V94 #199


Received: by ccmail from 3445a.DaytonOH.NCR.COM
>From ncrhub1!ucsd.edu![e-mail]
X-Envelope-From: ncrhub1!ucsd.edu![e-mail]
Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 06:33:35 EDT
Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 06:33:10 EDT
Received: from ncrgw2 by ncrhub1.NCR.COM id ba07109; 12 Sep 94 6:16 EDT
Received: by ncrgw2.NCR.COM; 10 Sep 94 10:12:46 EDT
    sendmail 8.6.9/UCSD-2.2-sun
    Sat, 10 Sep 1994 04:30:10 -0700 for tcp-digest-list
Received: by ucsd.edu; id EAA11034
    sendmail 8.6.9/UCSD-2.2-sun
    Sat, 10 Sep 1994 04:30:09 -0700 for tcp-group-ddist
Message-Id: <[e-mail]>
Date: Sat, 10 Sep 94 04:30:07 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #199
To: [e-mail]

TCP-Group Digest            Sat, 10 Sep 94       Volume 94 : Issue  199

Today's Topics:
                          [e-mail]
                      ax25 linux implementation?
                  Borland C++ 4.0x patches released
                             Mail failure

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 9 Sep 1994 23:41:36 -0400
From: [e-mail] (Frederick A. Peachman)
Subject: [e-mail]
To: [e-mail]

subscribe

--
Fred Peachman, Brookfield Ohio [e-mail]

------------------------------

Date: Fri, 9 Sep 1994 19:39:21 -0600
From: Glenn Davis <[e-mail]>
Subject: ax25 linux implementation?
To: [e-mail]

Thanks for the feedback on what an AX.25 bsd socket should do.  Can you
tell me where to find the Linux implementation (source) ?  I will model
my port after Linux.  Also, there was mention of a few applications built
on this model; where might they reside?

I just spent 8 hours finishing the ARP code.  It appears that ARP's are
not used on point-to-point links normally.  If I read the code correctly
BSDI just drops them on the floor.  This causes problems since you want
the interface that the packet arrived on, and this is not available when
you dequeue the mbuf.

How did the Linux implementation solve this?  My solution was:

Receive unsolicited ARP reply, or ARP request (broadcast):
 - use IP routing info, or interface this AX25 address last heard on to
   determine interface.  This could result in the wrong interface, and
   potentially requires storing a large number of AX25 address/interface
   pairs.

Receive directed ARP reply:
 - if it was in the table (unresolved request) use it, else drop the packet.

Send ARP reply:
 - send on interface from the arp cache (based on ARP request).

Send ARP discovery:
 - use IP routing, last interface this AX25 heard on, or send to all
   interfaces with a sockaddr in the AX.25 family.

The downside is that the arp table now needs an extra field for the interface.
On the other hand, there is no guarantee that the same AX25 address will not
be heard on more that one interface.

Glenn

------------------------------

Date: Fri, 09 Sep 94 17:19:00 -0000
From: [e-mail] (Mike Bilow)
Subject: Borland C++ 4.0x patches released
To: [e-mail]

The following files may be of interest to NOS developers.

BC4DOS32.ZIP   38K  9-05-94* How to develop 32-bit DOS apps using only Borland
                             C++ v4's RTM. Includes src.
BC4P01.ZIP      5K  9-05-94* Patch file for Borland C++ v4.00
BC4P02.ZIP    129K  9-05-94* Patch file for Borland C++ v4.00
BC4P03.ZIP    441K  9-05-94* Patch file for Borland C++ v4.00
BC4P04.ZIP     65K  9-05-94* Patch file for Borland C++ v4.00 to v4.02

These files are posted for dial-up download at N1BEE BBS, [phone] (to
28800 bps V.34/V.FC), but I don't know of any Internet sites.  I assume they
will be widely available on the Internet.  N1BEE BBS is also supports Fidonet
file requests to 1:323/107.

-- Mike


------------------------------

Date: Fri, 09 Sep 94 11:09:00 edt
From: Adminstrator <[e-mail]>
Subject: Mail failure
To: dayhub!3445a!ucsd.edu![e-mail]



User mail received addressed to the following unknown addresses:
  GPPGDAYTON/GPPGPOST/lshannon


------------------------------------------------------------------------------



Return-Path: <dayhub!3445a!ucsd.edu![e-mail]>
Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id
    <[e-mail]>; Fri, 09 Sep 94 11:09:20 edt
Received: by prowler.daytonoh.ncr.com; 9 Sep 94 11:04:41 EDT
Received: by dayhub.DaytonOH.NCR.COM; 9 Sep 94 11:04:15 EDT
Received: by 3445a.DaytonOH.NCR.COM; 9 Sep 94 11:04:47 EDT id AA779123936 Fri,
    09 Sep 94 11:18:56 EST
Date: Fri, 09 Sep 94 11:18:56 EST
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TCP-Group Digest V94 #198


Received: by ccmail from 3445a.DaytonOH.NCR.COM
>From ncrhub1!ucsd.edu![e-mail]
X-Envelope-From: ncrhub1!ucsd.edu![e-mail]
Received: by 3445a.DaytonOH.NCR.COM; 9 Sep 94 11:03:11 EDT
Received: by dayhub.DaytonOH.NCR.COM; 9 Sep 94 11:02:21 EDT
Received: from ncrgw1 by ncrhub1.NCR.COM id be12293; 9 Sep 94 11:01 EDT
Received: by ncrgw1.NCR.COM; 9 Sep 94 10:57:44 EDT
    sendmail 8.6.9/UCSD-2.2-sun
    Fri, 9 Sep 1994 04:30:13 -0700 for tcp-digest-list
Received: by ucsd.edu; id EAA25167
    sendmail 8.6.9/UCSD-2.2-sun
    Fri, 9 Sep 1994 04:30:11 -0700 for tcp-group-ddist
Message-Id: <[e-mail]>
Date: Fri,  9 Sep 94 04:30:06 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #198
To: [e-mail]

TCP-Group Digest            Fri,  9 Sep 94       Volume 94 : Issue  198

Today's Topics:
                           9k6 on-air test?
                  RE> KPC-9612 and X1J (IP routing)
                      TCP-Group Digest V94 #197
                   TCP-Group Digest V94 #197 (fwd)

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Thu, 8 Sep 1994 21:42:43 -0700 (PDT)
From: [e-mail] (Jerome Kaidor)
Subject: 9k6 on-air test?
To: [e-mail]

   Is there anybody on this list who's in the the San Francisco Bay
area and could help me with an on-the-air test of my new 9600-baud
packet station on 2M?

   It does receive, but there's nothing much happening on the local
9k6 frequency.  Just one station that keeps sending:

N6LDL-1>ID:Network node (#LGNODE)

   When I try to connect to it, nothing happens.  I assume its a NET/ROM
node, or somesuch.  But then, I have no idea if my transmit level is
reasonable.  Is there, perhaps, an AX25 BBS or two on 9k6?

  My goal is to get the thing working on 70CM tcp/ip, but it seemed
simpler to get the ax25 stuff working first....


                           - Jerry Kaidor, KF6VB



------------------------------

Date: Thu, 8 Sep 1994 20:46:36 -0600
From: [e-mail] (Evan E. Idler, Edmonton, AB  [192.75.200.5])
Subject: RE> KPC-9612 and X1J (IP routing)
To: [e-mail]

It was mentioned that it would be nice to have the kpc-9612 to route ip
on a remote site, as a dual port router.  Well, I had a nice talk with
Ruth Hull at the  Radio Amateur Of Canada Convention last month, and this
topic came up.  Well it seems, that If enought write The president of
KANTRONICS, they will port X1J over to run on it.  However if there is not
enought people requesting it, they will not be undertaking the project.

SO, IF YOU WANT IT YOU ALL HAVE TO TELL THEM THAT YOU WANT IT!!!!!!!!!!!

I beleive the person to Write your letter to is:

Karl Medcalf
Kantronics Co., Inc.
1202 E. 23rd Street
Lawrence, KS 66046


So write him, tell him how much you like your new KPC-9612, but how much
you would also like it to run X1J code.  If enough people ask, they will do
it.

73
EVAN


=======================================================================
Evan E. Idler                     |         Of All The Things I've Lost
[e-mail]          |         In Life, I Miss My MIND The
Edmonton, Alberta, Canada         |         Most!!!
Amateur Packet Radio Station VE6EEI [192.75.200.5]
=======================================================================

------------------------------

Date: Thu, 8 Sep 1994 10:20:54 -0800 (PDT)
From: [e-mail] (John Paul Morrison)
Subject: TCP-Group Digest V94 #197
To: [e-mail]

>
> Date: Wed, 7 Sep 1994 20:05:09 -0600
> From: Glenn Davis <[e-mail]>
> Subject: ax25 on bsd
> To: [e-mail]
>
> I have started the work to complete Brian Kantors AX25/KISS driver on BSDI.
> The stuff that is missing is: arp, good routing, and the socket interface
> (via pr_usrreq hook in the protocol switch table).
>
> Has anyone given much thought to the semantics of how sockets should be
> used when talking ax.25?  The IP stuff will remain pretty much the same,

Why don't you follow what the Linux AX.25 sockets do, since that is
already a working implementation.

> but I want to keep the ability to connect to non-ip packet bbs's.  The
> intent is to run a modified telnetd (using the ax25 protocols) to allow
> incoming connections.

I have patched BSD rlogind to work on a Linux AX.25 socket. It's not
really rlogin any more, as I've stripped out most of what's not needed
for AX.25, I just used it because it handled all the pty and login
shell stuff. I looked at telnetd for this, but it's too bloated and difficult
for me to figure out what to disable or fake for AX.25.

A linux program called axl listens on the AX.25 interface. When it
gets a connection, it forks off ax.rlogind, then goes back to
listening, and that gives you a login: prompt. You can login and get a
shell prompt. When you login you have to stty a few things (I think
/bin/login changes the tty modes, so even if I did set the line mode in
ax.rlogind, login would just change it back). I should change ax.rlogind
to use skeylogin to prompt for passwords. (which reminds me: does anyone
have an Skey available for an HP48 or other small calculator, so you
can calculate the response to the challenge without doing it by hand
or installing skey on every machine you visit)

It's quite horrible really, but it works. I don't think 1200bps packet
with a line at a time entry is useable for much with a login shell, but
instead of starting login, you could start up a bbs process, or some mail
stuff.


>
> glenn/ve6rsx
>

---------------------------------------------------------------------------
BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  --
[e-mail] [e-mail] [e-mail]
---------------------------------------------------------------------------

------------------------------

Date: Fri, 9 Sep 1994 11:38:39 +0200 (BST)
From: [e-mail] (Alan Cox)
Subject: TCP-Group Digest V94 #197 (fwd)
To: [e-mail]

In-Reply-To: <[e-mail]> from "John Paul Morrison"
at Se
p 8, 94 10:20:54 am
> Why don't you follow what the Linux AX.25 sockets do, since that is
> already a working implementation.

This seems sensible as we have nice tools and I'm also open to alterations
as suggested.

The AX.25 socket layer basically works as follows under Linux

 SOCK_RAW gives raw AX.25 access where the type of socket is
 the AX.25 PID. Datagrams or VC delivered raw and you fix it.

 SOCK_DGRAM UI AX.25 protocol frames. Marked with the AX.25 type

 SOCK_SEQPACKET AX.25 connection mode.

Since its derived from the BSD netccitt LAPB code the same hacks to
it should work roughly for BSD networking. It's got other stuff like
setting window, t1,n2,t3 via setsockopt.

Following that core setup would make most stuff portable (which as we all
know is good news).

Alan

------------------------------

End of TCP-Group Digest V94 #198
******************************

------------------------------

End of TCP-Group Digest V94 #199
******************************

------------------------------

End of TCP-Group Digest V94 #200
******************************

------------------------------

Date: Tue, 13 Sep 94 12:28:48 EST
From: [e-mail] (c.small-acacia-ele-student-90064116)
Subject: SCC = Baycom
To: [e-mail] (TCP-group relay)

G'day All,
  I was looking at the NOS scc drivers to see if they could be used for the
PackeTwin (result: i think so but it's beyond me!) and noticed that they
had as one of the options for the hardware as Baycom.  Is this the same
baycom as the one where you get something like a AM7910 chip that takes
the CTS/RTS lines as data?

The reason is that there is a SCC driver in Linux, there is neither a driver
for PackeTwin or baycom modems (yet).  I'm very keen to ditch the nos gateway
and let the Linux have direct access to the ports, rather than through the
SLIP link.

  - Craig vk2xlz

--
//   /\     |    |   |  | |   ... Craig Small   [44.136.8.58] ... ...
||==|--|====|====|===|==|=|   ... INTERNET: [e-mail]
\\   \/     |    |   |  | |   ... AMPR    : [e-mail]

------------------------------

End of TCP-Group Digest V94 #201
******************************

------------------------------

Date: Wed, 14 Sep 1994 02:36:17 -0700
From: Phil Karn <[e-mail]>
Subject: TCP-Group Digest V94 #197 (fwd)
To: [e-mail]

>The AX.25 socket layer basically works as follows under Linux

I haven't kept up with this stuff, so I have a few esoteric questions
based on my own implementation experience in NOS.

How are digipeaters specified? Separate routing table? Socket option?

What happens when you try to open two AX.25 connections between the
same pair of machines? This isn't permitted by AX.25 (there being no
port field) so something has to give. At the very least, you wouldn't
be able to access someone else's server at the same time they're
accessing yours. And suppose somebody logs into your server and then
disappears. You'd be kept from initiating a connection to their machine
indefinitely, unless you enable some sort of $#@!! keepalive mechanism.

IMHO, even if you're only nominally interested in one active session
at a time, port muxing mechanisms like those in TCP are very useful in
lessening the impact of these sorts of half-open connections.  Instead
of a difficult choice between channel-wasting keepalives and having to
deal manually with a half-open connection each time it occurs, you
merely waste a little memory on an idle TCP control block. Big
deal. :-)

That's why I've never been particularly excited about using AX.25 as a
transport protocol, especially in a multitasking OS that assumes a
"real" transport protocol like TCP. I understand why people are doing
it -- to make their systems maximally accessible. But the real goal
should be to make it unnecessary by putting TCP into the hands of as
many end users as possible.

Phil

------------------------------

Date: Wed, 14 Sep 1994 10:43:41 +0200 (BST)
From: [e-mail] (Alan Cox)
Subject: TCP-Group Digest V94 #197 (fwd)
To: [e-mail] (Phil Karn)

> How are digipeaters specified? Separate routing table? Socket option?
For AX.25 connections they are part of the sockaddr_ax25 structure. This I
can see causing fun in BSD which suffers the old 14 byte address problem unless
you rebuild from source. IPng will mean this has to get fixed in BSD anyway.
The IP layer uses entries added to the arp table with digipeated paths (as
per KA9Q), but doesn't work with them as Linux < the current pre 1.3.0
doesn't believe in devices with variable length headers. The new stuff
does it right.

> What happens when you try to open two AX.25 connections between the
> same pair of machines? This isn't permitted by AX.25 (there being no
> port field) so something has to give. At the very least, you wouldn't

EBUSY. Everything you say here about AX.25 being non ideal goes as true. AX.25
T3 polls seem to ensure this mostly works and BBS systems have survived with
the limitation 8)

> That's why I've never been particularly excited about using AX.25 as a
> transport protocol, especially in a multitasking OS that assumes a
> "real" transport protocol like TCP. I understand why people are doing
> it -- to make their systems maximally accessible. But the real goal
> should be to make it unnecessary by putting TCP into the hands of as
> many end users as possible.

A lot of the world isn't that TCP aware so AX.25 is useful. *BSD and Linux
have also changed where Unix like systems fit in for many people in that
they are very much client machines using AX.25 to talk to BBS systems
[should we insert the word 'legacy' here 8)]. For showing people _why_
TCP/IP over radio is neat binary ftp and Mosaic normally does the trick..

Alan

------------------------------

Date: Tue, 13 Sep 94 09:07 PDT
From: [e-mail] (Bruce Perens)
Subject: TEKK prices
To: [e-mail]

I recently ordered another TEKK transceiver. No surprise - with the
fall of the dollar of late prices have risen. For those unfamilliar
with the TEKK radios, they are 450 MHz 2-watt fixed-frequency units
that run on 10-12 volts and fit in a shirt pocket. Here's what they are
charging:

    T-Net Micro (KS-900)
    2 watt transceiver in cabinet:    119.90
    Transmitter only in cabinet:    92.90
    Receiver only in cabinet:    84.90

    Custom Frequency Charges per Crystal:    12.50

    T-Net Mini (the Micro works better for 9600)
    2 watt transmitter in "Omni-can":    129.90

    T-Mode Mini 2 watt transceiver with 4800 modem:    229.90
    M-48 4800 baud modem in "Omni-can":    114.90
    4800 baud modem bare PCB:    114.90

TEKK's phone numbers are: Voice 1-800-521-8355, FAX [phone].

A KS-900 transceiver and crystals now costs $150 by the time you're
done with shipping. This makes the $150 synthesized Ramsey kit
become attractive for the same application. Of course there's the time
investment of assembling and debugging the Ramsey kit, and you need a
shielded box (which comes with the TEKK).

    Bruce Perens

------------------------------

Date: Tue Sep 13 19:57:30 EST 1994
From: [e-mail]
Received: by prowler.daytonoh.ncr.com; 13 Sep 94 13:18:21 EDT
Received: by dayhub.DaytonOH.NCR.COM; 13 Sep 94 13:18:13 EDT
Received: by 3445a.DaytonOH.NCR.COM; 13 Sep 94 13:17:43 EDT
    id AA779477717 Tue, 13 Sep 94 13:35:17 EST
Date: Tue, 13 Sep 94 13:35:17 EST
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TCP-Group Digest V94 #201


Received: by ccmail from 3445a.DaytonOH.NCR.COM
>From ncrhub1!ucsd.edu![e-mail]
X-Envelope-From: ncrhub1!ucsd.edu![e-mail]
Received: by 3445a.DaytonOH.NCR.COM; 13 Sep 94 13:14:36 EDT
Received: by dayhub.DaytonOH.NCR.COM; 13 Sep 94 13:14:19 EDT
Received: from ncrgw1 by ncrhub1.NCR.COM id ar05029; 13 Sep 94 13:13 EDT
Received: by ncrgw1.NCR.COM; 13 Sep 94 12:52:01 EDT
    sendmail 8.6.9/UCSD-2.2-sun
    Tue, 13 Sep 1994 04:30:10 -0700 for tcp-digest-list
Received: by ucsd.edu; id EAA01122
    sendmail 8.6.9/UCSD-2.2-sun
    Tue, 13 Sep 1994 04:30:08 -0700 for tcp-group-ddist
Message-Id: <[e-mail]>
Date: Tue, 13 Sep 94 04:30:03 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #201
To: [e-mail]

TCP-Group Digest            Tue, 13 Sep 94       Volume 94 : Issue  201

Today's Topics:
                             Mail failure
                             SCC = Baycom

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 12 Sep 94 11:48:00 edt
From: Adminstrator <[e-mail]>
Subject: Mail failure
To: dayhub!3445a!ucsd.edu![e-mail]


User mail received addressed to the following unknown addresses:
  GPPGDAYTON/GPPGPOST/lshannon

------------------------------------------------------------------------------
Return-Path: <dayhub!3445a!ucsd.edu![e-mail]>
Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id
    <[e-mail]>; Mon, 12 Sep 94 11:48:51 edt
Received: by prowler.daytonoh.ncr.com; 12 Sep 94 11:42:14 EDT
Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 11:42:06 EDT
Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 11:42:13 EDT id AA779385538
    Mon, 12 Sep 94 11:58:58 EST
Date: Mon, 12 Sep 94 11:58:58 EST
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TCP-Group Digest V94 #200


Received: by ccmail from 3445a.DaytonOH.NCR.COM
>From ncrhub1!ucsd.edu![e-mail]
X-Envelope-From: ncrhub1!ucsd.edu![e-mail]
Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 11:37:40 EDT
Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 11:37:14 EDT
Received: from ncrgw1 by ncrhub1.NCR.COM id aa27896; 12 Sep 94 11:33 EDT
Received: by ncrgw1.NCR.COM; 12 Sep 94 11:32:25 EDT
    sendmail 8.6.9/UCSD-2.2-sun
    Mon, 12 Sep 1994 04:30:08 -0700 for tcp-digest-list
Received: by ucsd.edu; id EAA24362
    sendmail 8.6.9/UCSD-2.2-sun
    Mon, 12 Sep 1994 04:30:06 -0700 for tcp-group-ddist
Message-Id: <[e-mail]>
Date: Mon, 12 Sep 94 04:30:01 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #200
To: [e-mail]

TCP-Group Digest            Mon, 12 Sep 94       Volume 94 : Issue  200

Today's Topics:
                               autoampr
                      ax25 linux implementation?
                             Mail failure

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Sun, 11 Sep 1994 12:20:39 -0600
From: [e-mail] (Bdale Garbee)
Subject: autoampr
To: [e-mail], [e-mail]

I made a comment on one of the mailing lists the other day about having put
together some bits and pieces to help automate the management of an ampr.org
subnet.  A couple of folks contacted me asking for copies of the code.  I
wrote up a README file, shar'ed and gzip'ed it all, and you can acquire it
from

 ftp://winfree.gag.com/packet/gateways/autoampr.shar.gz

Don't bother unless you've got a Unix machine nearby, it's all shell script.

I hope it's useful to someone, has made my life a wee bit simpler.

73 - Bdale, N3EUA

------------------------------

Date: Mon, 12 Sep 1994 10:06:25 +0200 (BST)
From: [e-mail] (Alan Cox)
Subject: ax25 linux implementation?
To: [e-mail] (Glenn Davis)

> Thanks for the feedback on what an AX.25 bsd socket should do.  Can you
> tell me where to find the Linux implementation (source) ?  I will model
> my port after Linux.  Also, there was mention of a few applications built
> on this model; where might they reside?

All reside on ftp.linux.org.uk:/pub/Linux/Radio. The code is derived from
netccitt so you shouldn't have any trouble comparing it against your
netccitt code. The tools that exist currently in the main set are

 call - AX.25 connect program with YAPP support
 axl - An AX.25 listener - spawns a program for each AX.25
   connect [think of it as a dumb inetd]
 pms - Very crude PMS I wrote basically to prove I could
   rewrite AX.25 bulletins/mail into RFC822 and provide
   useful received from lines. Others are now working
   on this.
 axarp/axdelarp/axaddarp - original AX.25 arp manipulation. The current
   Linux net tools support AX.25 implicitly now so no
   special tools are used.
 listen - This won't port as it uses SOCK_PACKET (raw interface
   sockets) to monitor AX.25 KA9Q trace style. It's
   derived from the KA9Q trace routines.

 beacon - Send a regular beacon (dameon process)

 axattach - Attach an AX.25 iface (mirror of slattach)
 axsetcall - Set the AX.25 MAC address on an AX.25 interface
 mheard - List who has been recently heard. This uses the
   ax.25 routing table still under addition but collecting
   lists.

On ftp.ucsd.edu you will find the source to some raw socket stuff for talking
to microsat's. You'll also need the xview3 open windows toolkit to build this.
Other people are working on doing BBS code, I'm currently playing with a
very nice hostmode terminal for unix that I want to change to use AX.25
kernel sockets.

If you have any great ideas or think I've done something a paticularly stupid
way then I'm very open to suggestions. I'd rather we had one standard that
works
than one that works sort of, even if it means changing the Linux version of
the code.

> I just spent 8 hours finishing the ARP code.  It appears that ARP's are
> not used on point-to-point links normally.  If I read the code correctly
> BSDI just drops them on the floor.  This causes problems since you want
> the interface that the packet arrived on, and this is not available when
> you dequeue the mbuf.
>
> How did the Linux implementation solve this?  My solution was:

Linux doesn't consider the interface point-to-point in AX.25 mode (only
in SLIP mode). The data always happens to be available so that one never
occured. axattach on a (previously) SLIP link clears the pointopoint flags.

The one that was harder to fit nicely into the BSD socket semantics is the
opening phase. I added a little piece of code so that the commonly seen

 SABM
 [wait]
 SABM
 UA
 [Connected]
 UA
 [Reset Connection, Connected]

Doesn't cause a connection refused on the socket but waits until it opens
properly. If data has been sent and another UA turns up then it does reset.

Alan

------------------------------

Date: Mon, 12 Sep 94 06:43:00 edt
From: Adminstrator <[e-mail]>
Subject: Mail failure
To: dayhub!3445a!ucsd.edu![e-mail]



User mail received addressed to the following unknown addresses:
  GPPGDAYTON/GPPGPOST/lshannon


------------------------------------------------------------------------------

Return-Path: <dayhub!3445a!ucsd.edu![e-mail]>
Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id
    <[e-mail]>; Mon, 12 Sep 94 06:43:46 edt
Received: by prowler.daytonoh.ncr.com; 12 Sep 94 06:37:02 EDT
Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 06:36:52 EDT
Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 06:36:55 EDT id AA779367213
    Mon, 12 Sep 94 06:53:33 EST
Date: Mon, 12 Sep 94 06:53:33 EST
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TCP-Group Digest V94 #199


Received: by ccmail from 3445a.DaytonOH.NCR.COM
>From ncrhub1!ucsd.edu![e-mail]
X-Envelope-From: ncrhub1!ucsd.edu![e-mail]
Received: by 3445a.DaytonOH.NCR.COM; 12 Sep 94 06:33:35 EDT
Received: by dayhub.DaytonOH.NCR.COM; 12 Sep 94 06:33:10 EDT
Received: from ncrgw2 by ncrhub1.NCR.COM id ba07109; 12 Sep 94 6:16 EDT
Received: by ncrgw2.NCR.COM; 10 Sep 94 10:12:46 EDT
    sendmail 8.6.9/UCSD-2.2-sun
    Sat, 10 Sep 1994 04:30:10 -0700 for tcp-digest-list
Received: by ucsd.edu; id EAA11034
    sendmail 8.6.9/UCSD-2.2-sun
    Sat, 10 Sep 1994 04:30:09 -0700 for tcp-group-ddist
Message-Id: <[e-mail]>
Date: Sat, 10 Sep 94 04:30:07 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #199
To: [e-mail]

TCP-Group Digest            Sat, 10 Sep 94       Volume 94 : Issue  199

Today's Topics:
                          [e-mail]
                      ax25 linux implementation?
                  Borland C++ 4.0x patches released
                             Mail failure

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 9 Sep 1994 23:41:36 -0400
From: [e-mail] (Frederick A. Peachman)
Subject: [e-mail]
To: [e-mail]

subscribe

--
Fred Peachman, Brookfield Ohio [e-mail]

------------------------------

Date: Fri, 9 Sep 1994 19:39:21 -0600
From: Glenn Davis <[e-mail]>
Subject: ax25 linux implementation?
To: [e-mail]

Thanks for the feedback on what an AX.25 bsd socket should do.  Can you
tell me where to find the Linux implementation (source) ?  I will model
my port after Linux.  Also, there was mention of a few applications built
on this model; where might they reside?

I just spent 8 hours finishing the ARP code.  It appears that ARP's are
not used on point-to-point links normally.  If I read the code correctly
BSDI just drops them on the floor.  This causes problems since you want
the interface that the packet arrived on, and this is not available when
you dequeue the mbuf.

How did the Linux implementation solve this?  My solution was:

Receive unsolicited ARP reply, or ARP request (broadcast):
 - use IP routing info, or interface this AX25 address last heard on to
   determine interface.  This could result in the wrong interface, and
   potentially requires storing a large number of AX25 address/interface
   pairs.

Receive directed ARP reply:
 - if it was in the table (unresolved request) use it, else drop the packet.

Send ARP reply:
 - send on interface from the arp cache (based on ARP request).

Send ARP discovery:
 - use IP routing, last interface this AX25 heard on, or send to all
   interfaces with a sockaddr in the AX.25 family.

The downside is that the arp table now needs an extra field for the interface.
On the other hand, there is no guarantee that the same AX25 address will not
be heard on more that one interface.

Glenn

------------------------------

Date: Fri, 09 Sep 94 17:19:00 -0000
From: [e-mail] (Mike Bilow)
Subject: Borland C++ 4.0x patches released
To: [e-mail]

The following files may be of interest to NOS developers.

BC4DOS32.ZIP   38K  9-05-94* How to develop 32-bit DOS apps using only Borland
                             C++ v4's RTM. Includes src.
BC4P01.ZIP      5K  9-05-94* Patch file for Borland C++ v4.00
BC4P02.ZIP    129K  9-05-94* Patch file for Borland C++ v4.00
BC4P03.ZIP    441K  9-05-94* Patch file for Borland C++ v4.00
BC4P04.ZIP     65K  9-05-94* Patch file for Borland C++ v4.00 to v4.02

These files are posted for dial-up download at N1BEE BBS, [phone] (to
28800 bps V.34/V.FC), but I don't know of any Internet sites.  I assume they
will be widely available on the Internet.  N1BEE BBS is also supports Fidonet
file requests to 1:323/107.

-- Mike


------------------------------

Date: Fri, 09 Sep 94 11:09:00 edt
From: Adminstrator <[e-mail]>
Subject: Mail failure
To: dayhub!3445a!ucsd.edu![e-mail]



User mail received addressed to the following unknown addresses:
  GPPGDAYTON/GPPGPOST/lshannon


------------------------------------------------------------------------------


Return-Path: <dayhub!3445a!ucsd.edu![e-mail]>
Received: from prowler.daytonoh.ncr.com by gppgpost.daytonoh.ncr.com id
    <[e-mail]>; Fri, 09 Sep 94 11:09:20 edt
Received: by prowler.daytonoh.ncr.com; 9 Sep 94 11:04:41 EDT
Received: by dayhub.DaytonOH.NCR.COM; 9 Sep 94 11:04:15 EDT
Received: by 3445a.DaytonOH.NCR.COM; 9 Sep 94 11:04:47 EDT id AA779123936 Fri,
    09 Sep 94 11:18:56 EST
Date: Fri, 09 Sep 94 11:18:56 EST
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TCP-Group Digest V94 #198


Received: by ccmail from 3445a.DaytonOH.NCR.COM
>From ncrhub1!ucsd.edu![e-mail]
X-Envelope-From: ncrhub1!ucsd.edu![e-mail]
Received: by 3445a.DaytonOH.NCR.COM; 9 Sep 94 11:03:11 EDT
Received: by dayhub.DaytonOH.NCR.COM; 9 Sep 94 11:02:21 EDT
Received: from ncrgw1 by ncrhub1.NCR.COM id be12293; 9 Sep 94 11:01 EDT
Received: by ncrgw1.NCR.COM; 9 Sep 94 10:57:44 EDT
    sendmail 8.6.9/UCSD-2.2-sun
    Fri, 9 Sep 1994 04:30:13 -0700 for tcp-digest-list
Received: by ucsd.edu; id EAA25167
    sendmail 8.6.9/UCSD-2.2-sun
    Fri, 9 Sep 1994 04:30:11 -0700 for tcp-group-ddist
Message-Id: <[e-mail]>
Date: Fri,  9 Sep 94 04:30:06 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #198
To: [e-mail]

TCP-Group Digest            Fri,  9 Sep 94       Volume 94 : Issue  198

Today's Topics:
                           9k6 on-air test?
                  RE> KPC-9612 and X1J (IP routing)
                      TCP-Group Digest V94 #197
                   TCP-Group Digest V94 #197 (fwd)

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Thu, 8 Sep 1994 21:42:43 -0700 (PDT)
From: [e-mail] (Jerome Kaidor)
Subject: 9k6 on-air test?
To: [e-mail]

   Is there anybody on this list who's in the the San Francisco Bay
area and could help me with an on-the-air test of my new 9600-baud
packet station on 2M?

   It does receive, but there's nothing much happening on the local
9k6 frequency.  Just one station that keeps sending:

N6LDL-1>ID:Network node (#LGNODE)

   When I try to connect to it, nothing happens.  I assume its a NET/ROM
node, or somesuch.  But then, I have no idea if my transmit level is
reasonable.  Is there, perhaps, an AX25 BBS or two on 9k6?

  My goal is to get the thing working on 70CM tcp/ip, but it seemed
simpler to get the ax25 stuff working first....


                           - Jerry Kaidor, KF6VB



------------------------------

Date: Thu, 8 Sep 1994 20:46:36 -0600
From: [e-mail] (Evan E. Idler, Edmonton, AB  [192.75.200.5])
Subject: RE> KPC-9612 and X1J (IP routing)
To: [e-mail]

It was mentioned that it would be nice to have the kpc-9612 to route ip
on a remote site, as a dual port router.  Well, I had a nice talk with
Ruth Hull at the  Radio Amateur Of Canada Convention last month, and this
topic came up.  Well it seems, that If enought write The president of
KANTRONICS, they will port X1J over to run on it.  However if there is not
enought people requesting it, they will not be undertaking the project.

SO, IF YOU WANT IT YOU ALL HAVE TO TELL THEM THAT YOU WANT IT!!!!!!!!!!!

I beleive the person to Write your letter to is:

Karl Medcalf
Kantronics Co., Inc.
1202 E. 23rd Street
Lawrence, KS 66046


So write him, tell him how much you like your new KPC-9612, but how much
you would also like it to run X1J code.  If enough people ask, they will do
it.

73
EVAN


=======================================================================
Evan E. Idler                     |         Of All The Things I've Lost
[e-mail]          |         In Life, I Miss My MIND The
Edmonton, Alberta, Canada         |         Most!!!
Amateur Packet Radio Station VE6EEI [192.75.200.5]
=======================================================================

------------------------------

Date: Thu, 8 Sep 1994 10:20:54 -0800 (PDT)
From: [e-mail] (John Paul Morrison)
Subject: TCP-Group Digest V94 #197
To: [e-mail]

>
> Date: Wed, 7 Sep 1994 20:05:09 -0600
> From: Glenn Davis <[e-mail]>
> Subject: ax25 on bsd
> To: [e-mail]
>
> I have started the work to complete Brian Kantors AX25/KISS driver on BSDI.
> The stuff that is missing is: arp, good routing, and the socket interface
> (via pr_usrreq hook in the protocol switch table).
>
> Has anyone given much thought to the semantics of how sockets should be
> used when talking ax.25?  The IP stuff will remain pretty much the same,

Why don't you follow what the Linux AX.25 sockets do, since that is
already a working implementation.

> but I want to keep the ability to connect to non-ip packet bbs's.  The
> intent is to run a modified telnetd (using the ax25 protocols) to allow
> incoming connections.

I have patched BSD rlogind to work on a Linux AX.25 socket. It's not
really rlogin any more, as I've stripped out most of what's not needed
for AX.25, I just used it because it handled all the pty and login
shell stuff. I looked at telnetd for this, but it's too bloated and difficult
for me to figure out what to disable or fake for AX.25.

A linux program called axl listens on the AX.25 interface. When it
gets a connection, it forks off ax.rlogind, then goes back to
listening, and that gives you a login: prompt. You can login and get a
shell prompt. When you login you have to stty a few things (I think
/bin/login changes the tty modes, so even if I did set the line mode in
ax.rlogind, login would just change it back). I should change ax.rlogind
to use skeylogin to prompt for passwords. (which reminds me: does anyone
have an Skey available for an HP48 or other small calculator, so you
can calculate the response to the challenge without doing it by hand
or installing skey on every machine you visit)

It's quite horrible really, but it works. I don't think 1200bps packet
with a line at a time entry is useable for much with a login shell, but
instead of starting login, you could start up a bbs process, or some mail
stuff.


>
> glenn/ve6rsx
>

---------------------------------------------------------------------------
BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  --
[e-mail] [e-mail] [e-mail]
---------------------------------------------------------------------------

------------------------------

Date: Fri, 9 Sep 1994 11:38:39 +0200 (BST)
From: [e-mail] (Alan Cox)
Subject: TCP-Group Digest V94 #197 (fwd)
To: [e-mail]

In-Reply-To: <[e-mail]> from "John Paul Morrison"
at Se
p 8, 94 10:20:54 am
> Why don't you follow what the Linux AX.25 sockets do, since that is
> already a working implementation.

This seems sensible as we have nice tools and I'm also open to alterations
as suggested.

The AX.25 socket layer basically works as follows under Linux

 SOCK_RAW gives raw AX.25 access where the type of socket is
 the AX.25 PID. Datagrams or VC delivered raw and you fix it.

 SOCK_DGRAM UI AX.25 protocol frames. Marked with the AX.25 type

 SOCK_SEQPACKET AX.25 connection mode.

Since its derived from the BSD netccitt LAPB code the same hacks to
it should work roughly for BSD networking. It's got other stuff like
setting window, t1,n2,t3 via setsockopt.

Following that core setup would make most stuff portable (which as we all
know is good news).

Alan

------------------------------

End of TCP-Group Digest V94 #198
******************************

------------------------------

End of TCP-Group Digest V94 #199
******************************

------------------------------

End of TCP-Group Digest V94 #200
******************************

------------------------------

Date: Tue, 13 Sep 94 12:28:48 EST
From: [e-mail] (c.small-acacia-ele-student-90064116)
Subject: SCC = Baycom
To: [e-mail] (TCP-group relay)

G'day All,
  I was looking at the NOS scc drivers to see if they could be used for the
PackeTwin (result: i think so but it's beyond me!) and noticed that they
had as one of the options for the hardware as Baycom.  Is this the same
baycom as the one where you get something like a AM7910 chip that takes
the CTS/RTS lines as data?

The reason is that there is a SCC driver in Linux, there is neither a driver
for PackeTwin or baycom modems (yet).  I'm very keen to ditch the nos gateway
and let the Linux have direct access to the ports, rather than through the
SLIP link.

  - Craig vk2xlz

--
//   /\     |    |   |  | |   ... Craig Small   [44.136.8.58] ... ...
||==|--|====|====|===|==|=|   ... INTERNET: [e-mail]
\\   \/     |    |   |  | |   ... AMPR    : [e-mail]

------------------------------

End of TCP-Group Digest V94 #201
******************************

------------------------------

End of TCP-Group Digest V94 #202
******************************